最简单的选择是使用以下方法将 main 分支合并到 feature 分支中：

或者，您可以把它压缩成一行：

这会在 feature 分支中创建一个新的“合并提交”，将两个分支的历史记录联系在一起，从而为您提供一个看起来像这样的分支结构：

合并是不错的选择，因为它是一种非破坏性的操作。现有分支不会得到任何更改。这避免了变基操作的所有隐患（后面将会讨论）。

另一方面，这也意味着每次需要并入上游变更时，feature 分支将会产生一个无关的合并提交。如果 main 非常活跃，这可能会污染您的功能分支的历史记录。虽然可以使用高级 git log 选项来缓解此问题，但可能会让其他开发人员难以理解项目的历史记录。

作为合并的替代方法，您可以使用以下命令将 feature 分支变基为 main 分支：

这会移动整个 feature 分支，以在 main 分支的节点开始，从而有效地将所有新提交并入 main 中。但是，变基并不使用合并提交，而是为原始分支中的每个提交创建全新的提交来重写项目历史记录。

变基的主要优势在于您可以获得更干净的项目历史记录。首先，它不像 git merge 一样需要不必要的合并提交。其次，如上图所示，变基还会产生完美的线性项目历史记录—您可以在没有任何新拷贝的情况下，始终按照 feature 的提示找到项目的源头。这可以让您更轻松地使用 git log、git bisect 和 gitk 等命令导航项目。

但是，对于这种清晰的提交历史记录，存在两个需要权衡的地方：安全性和可追溯性。如果您不遵循变基的黄金法则，重写项目历史记录可能会对您的协作工作流造成潜在危害。另外，变基会丢失合并提交所带来的上下文—您无法看到上游变更何时被并入功能。

交互式变基可让您在提交移动到新分支时对提交进行更改。这甚至比自动变基更强大，因为这可以让您完全控制分支的提交历史记录。通常情况下，可用它来清理混乱的历史记录，然后再将功能分支合并到 main 中。

要开始交互式重基会话，请将 i 选项传递给 git rebase 命令：

这将打开一个文本编辑器，列出所有即将移动的提交：

这个列表准确地定义了执行变基后分支的样子。通过更改 pick 命令和/或重新排序条目，您可以使分支的历史记录看起来像您想要的任何样子。例如，如果第二次提交修复了第一次提交中的一个小问题，则可以使用 fixup 命令将它们压缩为一次提交：

当您保存并关闭文件时，Git 将根据您的指令执行变基操作，生成如下所示的项目历史记录：

像这样清除不重要的提交，可以让功能的历史记录更容易理解。这是 git merge 完全无法做到的事情。